|
|
|
|
|
|
|
and verbs require further analysis to determine whether they are truly actors, classes, business processes (or use cases), and/or methods. |
|
|
|
|
|
|
|
|
Figure 2.3.
Using a word processor such as Microsoft Word, you can document
a plain English, high-level description of how the user(s) will use
the system you're developing with Visual Basic. |
|
|
|
|
|
|
|
|
Identifying Candidate Classes and Actors in the Problem Statement |
|
|
|
|
|
|
|
|
Based on your problem statement, the following list represents candidate classes and actors: |
|
|
|
|
|
|
|
|
Samsona Bank Teller System |
|
|
|
|
|
|
|
|
In analyzing each actor/class candidate, you and/or your team determine whether each item is meaningful to the context of the business processes being addressed by your system. By meaningful, I mean something that represents a role performed by the user or external system, helps the user produce a product or service that is valuable to the business, and isn't too vaguely defined within the context of your proposed system. For instance, the word funds is too vague for your system because the teller doesn't create the funds nor place the funds into your system. She merely accepts funds from her customer or gives funds to him. Therefore, funds are eliminated from your list of candidates. |
|
|
|
|
|
|
|
|
If you're a beginning or intermediate object-oriented practitioner (an architect, analyst, designer, programmer, and tester), you might ask yourself why there is no mention of the customer in the problem statement. Answer: The customer isn't in the context of your system (your problem domain). The exchanging of cash or information between the teller |
|
|
|
|
|
